Thanks for this! Definitely an important step that we handle Int/UInt soon, because that is the most common used integer type in Swift.

I do however, think we need to give this some more thought. Especially since the JNI mode will probably be used a lot by Android folks, which is commonly 32-bit. If you have the following Swift function:

func f(i: Int)

with this PR it gets translated to

void f(long i)

however, the downcall to Swift would be Int64(fromJNI: i, ...), which is not compatible with Int in Swift. so that would not work. I am not sure if its ok to just drop the top 32-bits, if we are running on a 32-bit machine. Maybe we need some kind of annotation mode like the unsigned stuff? Or throwing an error, if we are not in Int32.min...Int32.max on 32-bit? What do you think?

Also we should add some codegen tests and runtime tests while we are it, as well as add the UInt to the @Unsigned annotation handling

I am aware of Int64 -> Int32 conversion problem but I didn't think about it as problem needed to be addressed in the same PR. To be honest I thought 32-bit is rare for Android, so I have no problem to work on solution for it in this PR.
I don't know much about annotations in Java, so for potential solutions I thought about SwiftInt java object which will throw IntegerOverflowException in those cases.
Of course I will add tests for it too :)

Thanks for the PR, this would be good to address.

Overall the two "modes" should behave the same wherever possible and it is a problem that they're a bit independent currently so this would be good to align the two.

32bit is very rare and AFAICS there is a number of prominent apps that choose to not support 32bit Android devices.

The Java annotation mentioned is the https://github.com/swiftlang/swift-java/blob/main/SwiftKitCore/src/main/java/org/swift/swiftkit/core/annotations/Unsigned.java so please have a look how we're using it in the ffm mode to mark something was an "U"Int. The imported parameters or return types basically get an @Unsigned long etc, this is valuable because users can then handle it and notice in the API description, without having to guess

I know 32-bit is rare these days. But since it's still a supported platform, for both Swift and the Swift Android SDK, I think we should still handle it. For example for us, most of our devices are 32-bit, and that is in the millions:)

OK by me to merge this and we can tackle it in another PR, just wanted to flag this, as we need to handle it somehow.
An idea could be sourcegen something similar to this:

@_cdecl()
func $f(i: jlong) {
  let swiftInt = Int64(fromJNI: i, ...)
  #if _pointerBitWidth(_32)
  guard swiftInt <= Int32.max, swiftInt >= Int32.min else {
    // throw overflow exception
  }
  #endif
}

maybe this could even just be in the extension Int: JavaValue methods.

Well we can't merge anything this week, so yes, let's please polish this up before branches get unlocked next week.

I committed small change with a proposed solution for check and basic tests. Let me know what you think, and if the response is positive, I'll cover rest of JNI cases(enum cases etc) and apply it to FFM.

This looks great!

I only have one comment regarding the implementation for maintainability. Up until now all conversions have just been done in the ConversionStep types. This includes any checks as well (if, guards), for example for nullable checks. As more people become interested in collaborating on the project, perhaps we should make sure we unify the way we do conversions. Just a bit worried that we deviate and do things differently in the project. Makes it harder for new contributors!

Was there a specific reason for introducing the "indirect" and "check" types? And not just doing it inside a ConversionStep?

Firstly, thank you @madsodgaard for sharing your concern :)

Was there a specific reason for introducing the "indirect" and "check" types? And not just doing it inside a ConversionStep?

Of course, but I realise that for others this may not be a sufficient reason. As someone who just started to contribute I felt NativeSwiftConversionStep already does a lot and I didn't want to add too much to it. From my perspective, it should handle conversion between Java and Swift, while other things, such as checking and validation, should be handled by something else to separate their responsibilities. That is why I wanted to create a separate mechanism for handling this; I believe that this approach increases maintainability. Of course, I won't insist on this if you and @ktoso decide that the current approach is better, I have no objection to adapting to it :)